Git Kata 1: New Local Repository

Step 1: Initialize a new repository#

Open a new terminal window. The command to edit and list files is given below.

The result will be something like this:

The first command group changes to the dk/storelist directory, opens storelist.txt in the text editor, and lists the files in dk/storelist. The only file in the dk/storelist directory is storelist.txt.

Leave the text editor open. We’ll be switching back and forth between the terminal and the editor to view and make changes to storelist.txt.

The command to initiate the new repository is given below.

When we run the command above, the result will be something like this:

The git init command does one thing only: it initializes the repository by creating the hidden .git directory. A Git repository consists of the .git directory and the files and sub-directories of the repository directory, dk/storelist. The repository directory and its subdirectories are the working directory, also known as the working tree. Files that are tracked by the repository are stored and edited in the working directory.

The command to set email and username for the local repository is given below.

The output will be something like this:

The next two commands use config to set the username and email address for the local repository. These values are stored in files under the .git directory. Git associates an identity with changes as they’re saved to the version history. If no identity is set, commands to record changes, called commits, to a repository index will return an error.

The command to list files is given below.

After executing the command above, the output will be something like this:

The ls command is used with the -A parameter to show all the files. This displays the hidden .git directory in dk/storelist. The ls .git command lists all the files in the .git directory. These files are managed by the Git program and shouldn’t be modified directly. The .git folder is the repository index. The index is a local database that stores the version history of changes made to the files in the working directory.

The command to get the repository status is given below.

The result of the command above will be something like this:

The git status command shows the status of all the files in the dk/storelist directory. The first execution shows that there’s one untracked file in the repository: storelist.txt. The git init command initializes a new repository, but that doesn’t cause any files in the working directory to be tracked.

The output of this command is explained as follows:

Step 2: Stage changes to a repository#

The command to add a file to the index and track it is given below.

The output of the command above will be something like this:

The git add command is used to stage changes in a repository. Changes to a repository that are staged will be part of the next commit to that repository. Git uses commits to save changes to the index. The list of commits, called the commit history, is the chronologically ordered version history of a Git repository. Commits are also used to push version history to a remote Git server.

The git add command stages the storelist.txt file. Files in a repository have a status of “tracked” or “untracked.” Prior to this command, storelist.txt was untracked, as we saw in the previous git status command. Running git add storelist.txt changes the status of storelist.txt to tracked.

The command to get the repository status is given below.

The output will be something like this:

The git status command is used to view the status of all the files in a repository. The output shows that the current branch is primary.

The output of this command is explained as follows:

Step 3: Commit changes to a repository#

The command to commit the changes to the repository is given below.

Note: Typing “Initial Commit” followed by the commands “Ctrl”+“O,” “Enter,” and then “Ctrl”+“X” resembles the key combinations used in the nano text editor to save and exit a file.

The output will be something like this:

This step creates a commit. A commit is a snapshot of the state of the tracked files in the working directory. The commit history of a repository is an ordered list of all commits in reverse chronological order. As new commits are added, they’re added to the top of the list, and older commits are pushed downward.

The git commit command creates the first commit in this repository. The default text editor, nano, is opened so that the commit comment may be added to the commit.

Each commit can (and should) have a comment added to it. Commenting commits is a best practice. All commits should have a brief but descriptive comment describing the changes that are included in the new commit. The first commit comment is, by convention, often “initial” or “first commit.” The commit made in this step has committed one change: the addition of the storelist.txt file.

The output of the command is:

Starting with this step, each Git kata that creates a new commit will include a history visualization. As new commits are added, the visualizations will be updated to display them. The visualizations listed with the katas are displayed horizontally, which makes it easy to see a short history. Longer histories are easier to see with a vertical format. We’ll see that on the command line in a later kata. Command-line and graphical Git tools display commit histories using a variety of visual formats.

Our repository now has a single commit, represented by a circle. The first commit is referred to as the root commit. This representation also shows two labels on the commit: the branch and the HEAD reference. We’ll cover branches in the next kata.

The HEAD reference is a symbolic reference (also called a ref) to the current branch. This reference tells Git where to apply the next commit. Switching branches updates the HEAD ref to point to the current branch. Git commands such as revert and reset, which are used to reverse changes by undoing commits, also modify the HEAD ref.

The command to get the repository status is given below.

The output of the command above will be something like this:

The git status command now shows that there are no uncommitted changes in the working directory.

The output of the command is:

Step 4: Make and commit changes to a file#

To swap lines in the file and save:

• Open the storelist.txt file.
• Swap the first row and the sixth row.
• Click “Ctrl”+“S” to save.

This step will demonstrate the process of making changes to a file and then committing those changes to the repository. First, we open the storelist.txt file and make a change by swapping two lines.

The command to get the repository status is given below.

After executing the command above, the output will be something like this:

The git status command shows that storelist.txt has been modified.

The output of the command is:

The command to commit the change to the repository is given below.

The result of the command above will be something like this:

This is the first commit we’ve made after modifying a file. The -a parameter tells Git to stage and commit all the modified and tracked files. It’s the equivalent of calling git add on every modified file, then git commit. The -m parameter allows us to include the comment on the command line. This is typically faster than opening a text editor, as we did in the previous step.

The output of the command is:

Note: Our repository now has two commits, represented by two connected circles. A Git commit history is a graph, in which each commit refers to the previous commit. The new commit that was just added contains a reference to its parent commit, which was the first commit in the repository.

The command to get the repository status is given below.

The result of the command above will be something like this:

The git status command now shows that the working tree (another term for the working directory) is clean, which means that there are no uncommitted changes in the working directory. When changes are present and unstaged and/or uncommitted, the working directory is referred to as dirty.

The output of the command is:

To swap lines in the file and save:

• Swap the third and fourth rows in storelist.txt.
• Click “Ctrl”+“S” to save.

This step makes and commits another change to storelist.txt.

The command to commit the change to the repository is given below.

The output of the command above will be something like this:

This step commits the second edit made to the storelist.txt file.

The output of the command is:

Note: The repository now has three commits. The HEAD ref continues to refer to the most recent commit on the current branch.

The command to get the repository status is given below.

When we execute the command above, the output will be something like this:

The git status command now shows that the working tree is clean again after committing the second change to storelist.txt.

Practice commands#

We’ve given a terminal and a table containing a list of commands discussed in this lesson. Try out these commands after running the terminal, and check out the results!